This invention relates to integrated circuit (IC) cards, such as smart cards, and methods for using IC cards for authentication purposes. This invention may also be extended to other types of IC devices with limited memory and processing capabilities, such as smart diskettes, electronic wallets, PC cards, and the like. More particularly, the invention relates to devices and methods that manage authentication status in a manner that permits restriction and/or extension of authentication depending on processing needs and situations.
Authentication systems are used for security purposes to verify the authenticity of one or more parties or entities during a transaction. Traditionally, authentication systems have been manual, involving personal recognition or quick verification of a party via some form of additional identification. One very familiar authentication process occurs when purchasing an item with a personal check. The sales clerk will process the check only if he/she recognizes the person writing the check or if the person presents another piece of identification (e.g., a credit card or driver""s license) to verify their authenticity as the specific person who is tendering the check.
Today, many authentication systems are electronic. A familiar electronic authentication system is a common credit card purchase. A card issuer issues a credit card to a consumer to enable the consumer to purchase items on credit. Credit cards that are primarily in use today consist of magnetic-stripe memory cards that have a single magnetic stripe (xe2x80x9cmag-stripexe2x80x9d) on one side. The magnetic stripe contains information about the card issuer, the consumer, and his/her account.
During a purchase transaction, the consumer presents the credit card to a sales clerk, who authenticates the card before finalizing the transaction. The credit card authentication process is typically performed xe2x80x9conlinexe2x80x9d. The sales clerk swipes the card through a reader, which extracts the card data from the magnetic stripe and transmits the data over a network to the card issuer (or a third party contracted to handle authentication requests). The card issuer checks to ensure that the card is still valid (i.e., has not expired), has not been revoked as being lost or stolen, and the corresponding account is below the authorized credit limit. If the authentication is successful, the card issuer returns an approval and the sales clerk completes the transaction. With conventional telecommunications and computerized processes, the entire credit card authentication process is typically handled in an acceptable length of time, such as a few seconds.
Today, there is increasing use of xe2x80x9csmart cardsxe2x80x9d in place of, or in addition to, conventional magnetic stripe cards. A xe2x80x9csmart cardxe2x80x9d is a thin card about the size of a credit card, with a built-in processor that enables the card to modify, or even create, data in response to external stimuli. The processor is a single-wafer integrated circuit (IC) which is mounted on an otherwise plastic card. For this reason, smart cards are often referred to as one class of xe2x80x9cintegrated circuit cardsxe2x80x9d or xe2x80x9cIC cardsxe2x80x9d.
As smart card technology becomes more pervasive, it paves the way for conducting a variety of new transactions, such as electronic money, which are not available with conventional mag-stripe cards. Smart cards also open up the arena for conducting certain new xe2x80x9cofflinexe2x80x9d transactions, which do not involve validating a card with a central authority. These offline electronic transactions are typically performed without the human intervention, such as from a sales clerk.
Smart cards are equipped with authentication capabilities used to establish the identity of an entity with which it is communicating. An identity can be an individual human being, a business, a piece of computing hardware, software code, a network node, an organizational role, or an accreditation agent. Smart cards also have authorization capabilities to control access to resources stored on the cards or elsewhere.
Typically, smart cards recognize a small, fixed number of generic authenticatable identities, typically only two or three. While a card may provide different ways to authenticate these generic identities, the access privileges granted to an authenticated identity do not depend directly on which method was used to perform the authentication. Smart cards have resorted to this collapsing of identities on the grounds of saving space and in the era of single-use, purpose-built cards this optimization caused little trouble.
Reusing or xe2x80x9caliasingxe2x80x9d a fixed number of generic identities across different datasets has a number of shortcomings in the era of multi-use and multi-application cards. First, all data needed by a particular identity must be organized in a way that does not trigger changes in authentications or authorizations as it is used. This, in turn, means that data access privileges become implicitly intertwined with data location and layout; changing the location of a file may change who can access the file and, if it is a key file, who can access other files. Secondly, data access policies that involve more than the number of generic identities supported by the card simply cannot be expressed.
Accordingly, it is desirable to design a smart card that can track an arbitrary number of identities and that makes data access policies independent of data file location.
Identities authenticated to today""s smart cards only persist for the duration of the session in which they are established. As a result, all identities that authorize a transaction or access to data on the card must authenticate themselves to the card each time it is used. This need to concurrently locate in time all the parties that must either approve or witness a card interaction severely limits the scope of applicability of the data and computational security provided by smart cards.
Accordingly, there is a need for improving smart cards to allow multiple uses of a card without requiring repeated authentication of an identity.
Additionally, in some instances it can be desirable to either restrict or extend the identities that are authenticated for a particular transaction. There can be several reasons for doing this. For example, it may be desirable to add one or more identities to the authenticated identities to enable operations that otherwise could not take place without them. Alternately, it may be desirable to limit the authenticated identities in a particular transaction because it is not necessary or desirable to have all of them authenticated. Yet, current smart cards do not provide for situationally-dependent, extension and restriction of authenticated identities on a transaction-by-transaction, or file-by-file basis.
Accordingly, there is a need for flexible, situationally-dependent extension and restriction of authenticated identities.
Apart from issues facing smart cards, another area of concern for facilitating a secure environment is the use of protected resources. One solution is to use capabilities to grant or deny access to the resources. A xe2x80x9ccapabilityxe2x80x9d is like a ticket that lets you do a particular thing. A key is a familiar example of a capability. Its possession is necessary and sufficient to gain access to what it protects. Neither the key nor the lock knows who is using it and the lock doesn""t maintain a list of all keys that can open it.
In a computer system, a capability ticket might permit someone to read a particular file. A ticket is presented to the file system, which validates the ticket and lets the ticket presenter read the file. Operating systems have been constructed using capabilities rather than access control lists to control access to their resources. Despite their usefulness in attacking the problems of access control lists, capabilities have not become popular for a number of reasons, including the difficulty of securely creating capability tickets.
Accordingly, there is a need for a system to securely create capabilities.
This invention concerns an integrated circuit (IC) device, such as smart cards, electronic wallets, PC cards, and the like, and various methods for authenticating identities and authorizing transactions based on the authenticated identities.
The IC device has a memory and a processor. The IC device maintains an identity authentication table in the memory to hold an arbitrary number of identities. The identity authentication table correlates identities with authentication protocols, so that different protocols can be used to authenticate associated identities. The identity authentication table also correlates counts with the identities. Individual counts specify a number of uses that the IC device can assume a corresponding identity has been authenticated without requiring the IC device to authenticate the identity for each use.
The IC device also maintains an authentication vector in memory. The authentication vector tracks identities in the identity authentication table that are currently authenticated by the IC device.
The IC device further maintains authorization tables in the memory and in association with particular files used in transactions. Each authorization table defines authorization for a particular transaction as a Boolean expression of the identities listed in the identity authentication table.
When the IC device receives an identity, it first looks to see if the identity is listed in the identity authentication table. If so, the IC device uses the corresponding protocol to authenticate the identity. If authentication proves successful, the IC device indicates in the authentication vector that this identity is currently authenticated.
One or more masks can be used to restrict and/or extend the authenticated identities for a particular transaction. Each file has associated therewith two masks-a restriction mask and an extension mask. The mask or masks are combinable with the authentication vector to modify the authenticated identities for a particular transaction.
When the IC device receives a request for a particular transaction, the IC device evaluates what identities need to be authenticated to satisfy the Boolean expression and gain authorization to perform the particular transaction using the authorization table. The IC device can combine one or more masks with the authentication vector to provide a modified authentication vector that modifies the vector to determine if the identities needed to satisfy the Boolean expression are currently authenticated, and if so, authorizes the transaction. After the transaction, the modified authentication vector can be returned to the original authentication vector having the original authenticated identities.
The count field in the identity authentication table allows the IC device to support xe2x80x9cpersistentxe2x80x9d authentication. If the count is nonzero (or some other threshold value), the IC device can assume, for purposes of determining authorization, that the identity has been authenticated and need not require receipt of the identity at this time. After each transaction involving the identity, the count is decremented.
The IC device is also configured to perform single command transactions. An instantaneous authentication command containing an operation and an identity are passed to the IC device. The device authenticates the identity using the protocol specified in the identity authentication table and is successful, performs the operation. Immediately thereafter, the IC device deauthenticates the identity so that only the single operation is performed.